系列：《當 AI Agent 走進風機現場：Claude × MCP × 工業維運的 30 天》
2026 iThome 鐵人賽 · Claude AI 組
告警進來的時候，天還亮著。
從辦公室開到現場四十分鐘。爬上去，進機艙，關掉頭燈。代碼在螢幕上，紅色的，很清楚。
這一步從來不是問題。控制器上有，SCADA 上也有，手冊裡也查得到——那個代碼對應一段明確的處置程序：檢查某個感測器、清潔某個接點、確認某個閥件、復歸、重啟。
四個步驟。他一項一項做完。
按下復歸。
什麼都沒發生。
再試一次。還是一樣。
他看了一眼窗外。天要黑了。
手冊回答的是「這個代碼該做什麼」。
它沒有回答 「做完了沒用，接下來怎麼辦」。
而在真實的風場，第二個問題出現的頻率遠比想像中高。原因很簡單： 告警代碼是症狀，不是根因。 同一個代碼在不同工況、不同季節、不同機齡下，背後可能是完全不同的東西。手冊寫的是最常見的那一條，而你現在遇到的顯然不是最常見的那一條。
站在機艙裡的那個人，這時候腦袋裡在跑什麼？
如果他是新人，他在想要打給誰。
如果他做了二十年，他在想的是別的東西——這台機上個月是不是也跳過同一個代碼，那次最後換了什麼才好。告警跳出來的前後三十秒，哪一個先跳、哪一個是連帶的。當時風速多少、功率多少，是滿載時跳的還是低風速時跳的，這兩件事的意義完全不同。同型的另外三台機組，有沒有出現過類似狀況。
還有最後一件，也是最現實的一件：哪些事現在可以在這裡做，哪些必須停手。 天快黑了，人在高處，機組還掛著。要不要通知營運方、要不要等廠商、要不要今天就到這裡。
這些東西沒有一項在手冊裡。
它們分散在歷史紀錄、即時數值、其他機組的案例，以及那個人做了二十年累積下來的判斷。
新人得打電話問人。老手憑經驗。而系統本身，什麼都不會告訴你。
這是我做風機維運這些年一直存在的問題，也是我想用這 30 天處理的問題。
我開了一個新對話，把上面那個情境原封不動貼進去：告警代碼是多少、手冊怎麼寫、我照做了、還是起不來，接下來該怎麼辦。
[截圖 1-1：Claude 在沒有任何工具的情況下的回答]
它給了一段結構完整、聽起來很專業的回答。它會建議我「重新確認前述步驟是否確實執行」、「檢查是否有其他關聯告警」、「必要時聯繫原廠技術支援」。
這些話沒有錯。但任何一個站在機艙裡的人都知道，這等於什麼都沒說—— 它只是把手冊又講了一遍，然後叫我打電話。
原因不是模型不夠聰明。是它缺了五樣東西：
一、它讀不到現在的數值。 我剛剛做完處置、按了復歸，機組現在的轉速、油溫、槳距角是多少？有沒有任何一項在動？這些數字就在控制器的暫存器裡，但沒有任何管道把它交給模型。 沒有即時值，就沒辦法判斷「處置到底有沒有產生任何效果」。
二、它不知道這台機的歷史。 上一次跳同一個代碼是什麼時候、當時的根因是什麼、最後怎麼排除的。這些紀錄可能存在，但模型讀不到。
三、它沒讀過 SOP，更沒讀過 SOP 以外的東西。 手冊只寫了第一層。第二層、第三層的排除順序，藏在技術通報、維修工單、和人的經驗裡。
四、它不知道哪些動作不該碰。 這一點在「照做了沒用」的情境下特別危險——人在排除失敗時，最容易開始「試試看」。 如果我給模型寫入權限，它會很樂意幫我調某個參數，而它完全不知道那台機組正掛在七十公尺高的地方。
五、它不知道自己講的話有沒有依據。 它分不出「這是手冊第 4.2 節寫的」和「這是我根據語感生成的」有什麼差別。在第一層排除失敗、開始往深處走的時候，這條界線是最重要的。
這五件事，就是接下來 30 天要一件一件補上的東西。
在開始之前，先講清楚兩條看起來很近、但走不通的路。
現在的模型 context 夠長，把 PDF 貼進去似乎就解決了。
但上面那個情境已經說明了問題：手冊本身就是不夠的。 把一份回答不了問題的文件塞進 context，只會得到一個更流暢的、把手冊複述一遍的答案。
就算退一步，只求它能正確引用手冊，這條路也有技術上的障礙。維修手冊裡大量出現的是型號、料號、扭力值、告警代碼——3021、M12x1.75、GB-0417 這種東西。這些字串在語意空間裡幾乎沒有辨識度，模型很容易在「3021」和「3012」之間滑過去，而且它不會告訴你它滑過去了。
更根本的是，這解決不了即時資料。手冊是靜態的，風機不是。
這條路的問題更隱蔽。
假設我很順利地讓模型讀到一個數值，80。
80 是什麼？ 是齒輪箱油溫 80°C，還是發電機轉速 80 rpm，還是某個百分比？這筆數值是三秒前的還是三小時前的？感測器當時的狀態是正常的嗎？如果 Modbus 讀取失敗，回傳的是 0——那到底是「真的是 0」還是「拿不到」？
模型不會問這些問題。它會直接拿 80 去推理，然後給你一段很有說服力的分析。
工業場景與一般應用最大的差別就在這裡：一個看起來合理但基於錯誤前提的答案，比一個「我不知道」危險得多。 尤其是在第一層排除已經失敗、人開始焦慮的時候。
先看終點。
[圖 1-1：architecture-v1.svg]
這張圖裡，實線的框是現在就有的，虛線的框是接下來 30 天要一層一層裝上去的。
最上面是人類工程師。我特意把人放在最頂層，而不是畫在旁邊當備案——這是整個系列最重要的一個立場，後面會反覆回到這裡。
最下面兩個灰色的框，一個是風機控制器，一個是維修 SOP 語料。它們一直都在，只是現在的 Agent「連不上」、「讀不到」。
中間那四層虛線，就是這 30 天的工作。
| 幕 | Day | 要補上的能力 |
|---|---|---|
| 一 | 1–4 | 環境與第一個 MCP server——讓 Agent 有手 |
| 二 | 5–11 | 工業通訊、資料契約、錯誤處理、唯讀安全閘 |
| 三 | 12–19 | SOP 檢索、混合搜尋、量化評測 |
| 四 | 20–23 | 引用來源、流程封裝、拒答機制 |
| 五 | 24–28 | 完整診斷、衝突處理、主動告警、部署 |
| 六 | 29–30 | 十個坑，以及回答 Day 1 的問題 |
其中 Day 13 是專門為今天這個情境寫的。那一篇沒有任何程式碼，標題是「Alarm 不等於 Root Cause」，講的就是為什麼「照著手冊做完還是不行」會發生，以及有經驗的人在那個時刻是怎麼想的。
現在市面上關於 AI Agent 的討論，絕大多數在回答同一個問題：Agent 能做到什麼？
在工業現場，我認為要先回答另一個問題：Agent 絕對不該做什麼？
一個能讀資料的 Agent 出錯，成本是一次誤判。一個能寫入設備的 Agent 出錯，成本是一台正在運轉的機組。
而今天那個情境，正是最容易出事的時刻。
第一層排除失敗了。人在高處，天快黑了，機組還停著。這種時候，人會開始試——調一個參數看看、跳過一個保護看看、反正先讓它轉起來再說。
這種時刻最需要的不是一個什麼都敢做的助手，是一個知道停在哪裡的助手。
所以這套系統從第一行程式碼開始就設定：所有對設備的存取預設唯讀。 任何寫入路徑都必須同時滿足三件事——在白名單裡、經過人類二次確認、留下操作日誌。三者缺一不可。
架構圖上那個珊瑚色的「唯讀閘」，跟最上面的「人類工程師」是同一個顏色。這不是配色巧合。它們是同一件事：人的控制邊界。
你也可以注意到，右邊 RAG 那一側沒有這個閘——讀文件不需要，動設備才需要。這個不對稱本身就是設計。
我想講清楚這 30 天的定位：這不是一個 AI 工程師找了風機題目來做 Demo，而是一個做風機的人把 AI 帶進自己的專業。
差別會在第三幕特別明顯。那一段每一篇都綁在「照著手冊做完還是不行」這個情境上——為什麼關鍵詞檢索有時候比語意搜尋可靠、為什麼向量搜尋會把料號吃掉、為什麼檢索效果一定要量化才知道有沒有用。
有幾件事我想在第一天就說清楚，因為它們會影響你怎麼看後面 29 篇的每一個數字。
所有效能數值都會真的跑。 召回率、MRR、延遲、重排序前後的名次變化，全部是實際執行的結果。如果某天實驗跑不出來，我會改寫成定性討論，不會補一個看起來合理的數字上去。
所有圖表會標示資料性質，是 模擬資料 / Synthetic 還是 實測結果 / Real Experimental Result。
所有風機資料都是自建模擬。 這個系列不會使用任何營運方的實際運轉資料或廠商專有技術文件。第 5 天我會用 pymodbus 架一台虛擬風機，之後所有的讀值都來自它。
程式碼全部開源，同一個 repo 每天長大一點。 不是 30 個互不相干的小程式。到第 30 天，git clone 下來就是一套完整的東西。
沒有。
這是 30 篇裡唯一一篇這個欄位是空的。今天只有一個問題、一張圖，和一個承諾。
明天開始裝東西。
Claude、MCP、PLC 到底各自扮演什麼角色？在寫任何一行程式之前，得先把職責邊界劃清楚——哪些事該由模型決定，哪些事根本不該讓模型碰。
repo github.com/dofliu/wind-agent-30 · tag day01-architecture
iThome鐵人賽
看影片追技術